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1.1  BACKGROUND 

With  the  advent  of  computer  graphics  systems,  product  defini¬ 
tion  data,  including  geometric  and  textual  information  that  was 
formerly  documented  with  engineering  drawings,  can  be  formulated 
and  stored  electronically.  However,  the  communication  of  these 
data  to  various  manufacturing  and  control  functions,  such  as 
process  planning,  fabrication,  assembly,  and  inspection,  is  by  and 
large  still  carried  out  by  transmitting  hardcopies  of  engineering 
drawings . 

"The  objective  of  the  Product  Definition  Data  Interface  (PDDI) 
Project,  sponsored  by  the  Integrated  Computer-Aided  Manufacturing 
(ICAM)  Program  Office  of  the  United  States  Air  Force,  is  to  de¬ 
velop  and  demonstrate  an  exchange  specification  which  would  allow 
the  replacement  of  engineering  drawings  with  an  electronic  inter¬ 
face  between  engineering  and  manufacturing  functions.  The  PDDI 
Project  is  organized  into  two  tasks: 

•  Task  I  -  Evaluation  and  Verification  of  the  Initial 
Graphics  Exchange  Specification  (IGES). 

•  Task  II  -  Development  and  Demonstration  of  a  Product 
Definition  Data  Interface. 

The  Initial  Graphics  Exchange  Specification  (IGES)  is  a  format  for 
the  digital  representation  of  data  needed  to  define  a  part  or  an 
assembly.  It  was  developed  in  response  to  the  needs  of  industry 
for  a  solution  to  the  problem  of  interfacing  dissimilar  CAD 
systems.  Version  1.0  of  IGES  has  now  been  incorporated  as  part  of 
an  American  National  Standard  (ANSI  Y14 . 26M-1981) .  Later  versions 
of  IGES  are  at  various  stages  in  the  cycle  of  updating  the  ANSI 
Standard . 

1.2  SUBJECT  OF  THIS  REPORT 

Vhis  report  is  concerned  with  Task  I  of  the  PDDI  project  and 
describes  the  establishment  of  a  test  methodology  for  evaluating 
the  effectiveness  of  IGES  implementations.  The  work  is  concerned 
with  three  fundamental  objectives  regarding  IGES: 

•  Establishment  of  a  test  methodology  and  procedures  to 
evaluate  IGES  translators. 

•  Determination  of  the  extent  to  which  IGES  defines  product 
definition  data. 

•  Evaluation  of  the  level  to  which  the  CAD  vendor/user 
community  has  been  able  to  implement  IGES,  and  the 
identification  of  problems  in  current  implementations. 

— Y 
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The  test  methodology  established  in  this  project  can  serve 
as  a  baseline  from  which  future  test  methodologies  for  sub¬ 
sequent  versions  of  IGES  can  be  developed.  In  addition,  the 
test  results  of  this  effort  have  served  as  a  valuable  source  of 
baseline  information  for  the  Task  II  work. 

1.3  TEST  APPROACH 

The  approach  taken  to  address  these  issues  involved  field  test¬ 
ing  of  twelve  different  CAD  systems  to  assess  their  ability  to 
generate  and  interpret  product  definition  data  in  an  IGES  for¬ 
mat.  The  tests  did  not  exhaustively  examine  every  aspect  of 
IGES  but  did  provide  an  in-depth  evaluation  of  current  1983 
IGES  implementations  and,  as  such,  identified  specific  problems 
encountered  with  current  versions  of  vendor/user  IGES  software. 
In  addition,  improvements  that  can  be  made  to  the  Standard  to 
positively  impact  translator  development  and  operation  were 
determined.  These  tests  represent  the  most  comprehensive 
evaluation  of  IGES  performed  to  date. 

1-4  REPORT  ORGANIZATON 

This  report,  which  is  the  final  report  of  Task  I  activi¬ 
ties.  is  organized  into  three  volumes.  This  volume,  Volume  I, 
provides  an  executive-level  summary  of  the  entire  Task  I 
effort.  Volume  II  presents  the  details  of  the  approach  to 
testing,  test  evaluation,  and  the  findings  and  recommendations 
as  they  apply  to  the  ANSI  Standard  Y14. 26M-1981.  Volume  III 
concentrates  on  the  test  methodology,  and  should  prove  useful 
to  those  in  the  field  who  wish  to  perform  their  own  testing. 

To  this  end.  Volume  III  discusses  the  test  methodology  in  a 
general  sense  as  contrasted  with  Volume  II  which  addresses  the 
specific  results  of  Task  I  testing.  A  set  of  appendixes  to 
Volume  II  include  examples  of  some  of  the  more  detailed  mater¬ 
ial  used  during  the  program. 


1-2 


FTR560130001U 
I- February  1984 


2.0  THE  IGES  CONCEPT 

IGES  activity  was  initiated  by  the  requirements  of  industry 
for  a  near-term  solution  to  the  needs  of  interfacing  current 
graphics  systems.  The  Air  Force  ICAM  program,  other  DoD  agen¬ 
cies  such  as  the  Array,  Navy,  and  NASA,  and  the  NBS  have  served 
as  a  catalyst  in  establishing  the  IGES  concept.  The  need  for  a 
near-term  solution  was  precipitated  by  organizations  that  had 
purchased  systems  from  different  vendors,  and  organizations 
that  understood  the  advantage  of  direct  digital-data  exchange 
with  suppliers  and  subcontractors. 

The  problem  is  that  each  CAD  vendor  typically  has  a  unique 
and  proprietary  "native"  format  for  the  representation  of  data 
necessary  to  define  a  product.  In  order  to  make  use  of  infor¬ 
mation  generated  by  one  CAD  system  (A)  on  a  second  CAD  system 
(B),  a  translator  must  be  developed  to  go  from  A's  native 
format  to  B’s  native  format,  and  a  second  translator  developed 
to  go  from  B's  format  back  to  A's.  This  problem  grows  quickly 
as  more  CAD  systems  are  added  -  six  translators  are  required 
for  three  different  CAD  systems  as  shown  in  Figure  2-1  below. 


Figure  2-1  The  CAD/CAD  Interface  Problem 
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As  a  way  of  circumventing  this  customized  translator  de¬ 
velopment  problem,  IGES  defines  a  "neutral"  data  file  as. a 
means  of  linking  dissimilar  systems  as  depicted  in  Figure  2-2. 


I6fcS  FILES. 


•  FORMAT 

•  STRUCTURE 

•  REPRESENTATION  OF  POD 


I 

Figure 


2-2  Communication  of  Product  Definition  Data  ( PDD) 
IGES 


Usin 


The  sending  system  produces  a  data  file  in  IGES  format  which  is 
then  transferred  to  and  read  by  the  receiving  system.  This  is 
accomplished  by  using  a  computer  program,  called  an  IGES 
pre-processor,  which  translates  the  product  definition  from  the 
original  format  into  IGES  format.  Similarly,  IGES  post-pro¬ 
cessor  software  automatically  translates  product  definition 
data  in  IGES  format  into  the  format  used  by  the  receiving 
system.  These  pre-and  post-processor  software  programs  are 
system  dependent  and  are  supplied  by  the  CAD  system  vendor  or, 
in  some  cases,  developed  by  the  system  user. 

An  assessment  of  IGES,  therefore,  also  entails  an  assess¬ 
ment  of  the  level  of  vendor,  user,  and  third  party  development 
of  IGES  preand  post-processor  software.  An  evaluation  of  pro¬ 
cessor  implementations  together  with  an  analysis  of  the  IGES 
Standard,  as  performed  during  Task  I,  provided  an  overall 
evaluation  of  IGES. 
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IGES  is  based  on  the  engineering  drawing  representation  of 
product  definition  data  with  Version  1.0  specifically  oriented  to 
mechanical  applications.  At  this  point  in  time,  IGES  Version  2.0 
has  been  released  by  the  National  Bureau  of  Standards  (NBS)  and 
work  on  Version  3  is  ongoing  by  the  NBS-managed  IGES  committees. 

The  procedures  by  which  IGES  is  adopted  as  an  ANSI  standard, 
however,  require  a  certain  amount  of  time  lag  between  the  release 
of  an  IGES  version  and  the  publication  of  the  corresponding  ANSI 
documentation.  Thus,  although  IGES  is  continuously  evolving,  the 
ANSI  Standard,  which  is  the  focus  of  attention  of  Task  I  work,  is 
defined  by  IGES  Version  1.0.  The  test  procedures,  therefore,  were 
specifically  applied  to  test  those  features  of  IGES  defined  in 
Version  1.0.  In  those  cases  where  later  IGES  versions  correct 
errors  or  more  clearly  describe  concepts,  these  later  inter¬ 
pretations  have  been  used. 

Three  attributes  of  the  product  definition  data  file  are 
specified  by  IGES: 

•  File  format 

•  File  structure 

•  Representation  of  individual  elements 

geometry 

annotation 

relationships 

IGES  Version  1.0  files  are  in  ASCII  format  with  80  characters/rec¬ 
ord.  The  fundamental  unit  of  information  in  IGES  is  the  entity. 
IGES  defines  entities  to  represent  geometric  elements,  such  as 
points,  curves  and  surfaces,  annotation,  and  other  elements  that 
enhance  product  descriptions,  such  as  subfigures,  groups  and 
views.  Thus,  an  IGES  file  is  a  collection  of  entity  descriptions. 
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3.0  IGES  REPRESENTATION  OF  ENGINEERING  DRAWINGS  AND  PART  MODELS 


Information  contained  on  an  engineering  drawing  can  be 
separated  into  three  catagories: 

•  Geometric  information  required  to  define  the  part. 

•  Fabrication  information  required  to  produce  the  part 
including  tooling  and  inspection. 

•  Assembly  information  required  to  show  the  relationship 
of  a  part  to  a  subassembly  or  final  product. 

Two-dimensional  geometry  is  represented  in  IGES  by  simple  geo¬ 
metric  entities  such  as  lines,  arcs,  conics,  and  parametric 
cubic  splines  as  shown  in  Figure  3-1. 


GEOMETRY: 


Figure  3-1  Geometric  Entity  Representation  of  Part  Geometry 

Three-dimensional  models  can  be  represented  using  the  IGES 
surface  entities  such  as  the  ruled  surface,  tabulated  cylinder, 
and  parametric  cubic  patch,  as  well  as  line  and  curve  enti¬ 
ties.  Solid  modeling  is  not  supported  in  either  Version  1.0  or 
2.0.  Part  features,  such  as  flanges,  holes,  and  webs,  are  not 
represented  as  specific  entities  but  rather  as  collections  of 
these  basic  geometric  curve  and  surface  elements. 
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The  majority  of  IGES  annotation  is  built  from  three  basic 
entities  -  text  (general  notes),  leaders,  and  witness  lines. 
Annotative  features  are  represented  by  IGES  as  combinations  of 
these  basic  entities.  For  example,  a  linear  dimension  entity 
is  made  up  of  a  general  note,  two  leaders,  and  zero  to  two 
witness  lines. 

IGES  structure  entities  provide  several  mechanisms  to 
extend  the  capabilities  of  the  pre-defined  entity  set  and  to 
add  meaning  to  an  IGES  entity  by  specifying  relationships  and 
attributes.  These  structure  entities  include  the  subfigure, 
associativity,  property  and  MACRO  entities.  Additional  details 
of  the  IGES  file  structure  and  entity  definitions  can  be  found 
in  ANSI  Y14 . 26M-198 1 ,  and  Volume  II  of  this  report. 
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4.0  TASK  I  APPROACH 


The  principal  means  used  to  provide  an  assessment  of  IGES 
was  through  a  series  of  field  tests.  Twelve  CAD  systems 
equipped  with  IGES  translators  were  tested  at  either  user  or 
vendor  sites  by  applying  the  test  procedures  developed  during 
the  project.  The  test  procedures,  which  are  discussed  in  the 
next  section,  address  the  overall  problem  of  evaluating  product 
definition  data  converted  from  a  CAD-vendor-specific  format  to 
an  IGES  representation  (pre-processing),  and  from  IGES  back 
into  a  specific  CAD  format  (post-processing).  Vendors  and 
users  included  in  the  field  testing  are  listed  in  Table  1  below. 

Field  testing  was  based  on  the  ability  of  actual  CAD  sys¬ 
tems  to  translate  product  definition  data  that  are  represented 
in  IGES  data  files.  In  order  to  create  these  files,  three 
tasks  were  required: 

•  Selection  of  sample  parts 

•  Generation  of  engineering  drawings 

•  Development  of  IGES  files. 

The  first  step  involved  the  selection  of  parts  to  be  mode¬ 
led.  Four  sample  aerospace-type  parts  were  selected  for  use 
during  testing.  Each  part  may  be  generally  classified  into  one 
of  four  categories  -  sheet  metal,  turned,  composite,  and  ma¬ 
chined.  Parts  selected  for  testing  represent  simplified  ver¬ 
sions  of  actual  production  parts.  Simplifications  of  redundant 
part  features  were  made  to  reduce  the  number  of  entities  to  a 
manageable  level  for  testing  yet  still  provide  meaningful  test 
data.  Since  IGES  is  primarily  based  on  a  set  of  discrete 
elements,  or  entities,  as  described  in  the  previous  section, 
little  has  been  lost  through  these  simplifications. 


Table  1-1  IGES-Evaluat ion  Test  Participants 


Vendors 

Users 

• 

Applicon 

• 

Boeing-CI IN 

• 

CDC-CD2000 

• 

Ford-PDGS 

• 

Calma 

• 

McDonnell  Douglas-CADD 

• 

Computervision-CADDS4X 

• 

Gerber 

• 

Intergraph 

• 

IBM -CAD AM 

• 

McAu to -UN I GRAPH ICS 

• 

MCS-ANVIL  4000 
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Figure  4-1  shows  Che  four  parts  selected  for  testing.  The 
upper  portion  of  the  figure  shows  the  sheet  metal  and  machined 
parts  from  the  leading-edge  extension  of  the  F-18  aircraft  man¬ 
ufacturing  by  McDonnell  Douglas.  The  composite  part  is  from 
the  wing  trail ing-edge  flap  structure  of  an  F-18.  The  turned 
part  is  a  truncated  version  of  a  part  used  in  the  CAM-I  Geomet¬ 
ric  Modeling  Project. 


COMPOSITE  PART 


TURNED  PART 


Figure  4-1  Test  Parts 

Blueprints  of  engineering-release  quality  were  created  for 
the  four  parts  on  the  McDonnell  Douglas  CADD  system.  These 
prints  were  then  reviewed  by  Booz,  Allen  design  engineers  and 
manufacturing  personnel  representing  several  aerospace  com¬ 
panies  to  comment  on  company-specific  practices  that  may  have 
been  present.  Suggested  changes  were  included  in  the  final 
part  drawings. 


M-2 
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The  last  step  involved  the  actual  development  of  the  test 
files,  where  the  blueprints  representing  the  four  parts  were 
turned  into  CAD  models.  Before  a  part  was  coded  into  IGES 
format,  it  was  necessary  to  determine  exactly  what  should  be 
included  in  the  test  file.  Ideally,  one  would  include  the 
entire  part  with  all  associated  views  and  annotations.  How¬ 
ever,  the  resultant  IGES  file  would  contain  hundreds,  or  even 
thousands  of  instances  of  a  few  commonly  used  entities  such  as 
lines,  arcs,  leaders  and  notes,  and  may  not  contain  all  types 
of  entities  IGES  is  capable  of  supporting.  Such  a  file  would 
not  provide  a  comprehensive  test  of  IGES  implementation.  To 
ensure  that  the  test  files  exercised  the  full  range  of  IGES 
capabilities,  features  were  selectively  added  to  the  sample 
parts  to  incorporate  those  IGES  entities  not  already  included. 

Another  item  that  must  be  considered  is  the  model  represen¬ 
tation  to  be  used  to  describe  the  part.  Currently  IGES  is 
capable  of  portraying  CAD  models  that  are  either  2D,  3D  wire¬ 
frame,  or  3D  wireframe  with  surfaces.  Following  the  normal 
engineering  convention,  2D  models  were  developed  for  the  sheet 
metal  and  composite  parts  while  2D  and  3D  models  were  developed 
for  the  turned  and  machined  parts.  The  composite  part  was 
developed  as  two  separate  models  since  the  flat  pattern  is 
treated  as  a  separate  drawing  by  manufacturing.  In  total, 
seven  part  models  were  created.  Table  1-2  shows  the  types  of 
representations  developed  from  the  four  parts. 


Table  1-2  Models  Developed  To  Represent  The  Sample 


Pact  Name 


2D 


3D  Wireframe 


3D  Wireframe 
And  Surface 


Sheet  Metal 

Turned 

Composite 


X 

X 

X(Rib).  X(Flat) 


Machined 


X 


X 
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In  order  to  generate  the  IGES  test  files  efficiently  and 
with  few  errors,  the  actual  coding  of  the  files  utilized  a  com¬ 
bination  of  manual  and  computer  translation.  The  parts  were 
first  modeled  on  the  McDonnell  Douglas  CADD  design  system.  The 
sample  part  representations  were  then  transferred  from  CADD  to 
UNIGRAPHICS  using  a  CADD-to-UNIGRAPHlCS  software  interface. 

The  next  step  was  the  creation  of  the  IGES  files  from  the 
UNIGRAPHICS  CAD  system.  An  IGES  pre-processor  from  the  McAuto 
UNIGRAPHICS  CAD  system  was  used  to  generate  the  majority  of 
simple  wireframe  part  geometry.  After  pre-processing,  the 
files  were  manually  checked  to  verify  the  validity  of  the 
data.  Manual  changes  were  made  to  the  files  where  discrep¬ 
ancies  occurred.  Annotation,  three-dimensional  surfaces,  and 
other  advanced  structural  entities  were  hand  generated  and 
added  to  the  files.  The  hand  generation  was  based  on  IGES 
Version  1.0  with  Version  2.0  used  to  provide  clarification. 
Figure  4-2  below  presents  a  flowchart  of  the  steps  involved  in 
the  generation  of  IGES  test  files. 

A  working  group  of  key  members  from  the  IGES  community  was 
formed  to  help  in  the  selection  of  choices  among  alternate 
representations  for  certain  features,  and  to  answer  questions 
on  interpretation  of  the  IGES  specification.  The  working  group 
consisted  of  Bradford  M.  Smith,  chairman  of  the  IGES  Committee, 
Philip  R.  Kennicott,  chairman  of  the  Extensions  and  Repair  sub¬ 
committee,  and  Michael  Liewald,  the  chairmen  of  the  Test,  Eval¬ 
uate  and  Support  subcommittee. 


sample 

PARTS 


CA00 

DESUN  SYSTEM 


CAO  I 

MODEL  19 


C AO D -UNI  GRAPH  I C  sj 
INTERFACE 


UNIGRAPHICS  I 
PART  MODEL  ■ 


HIGHER-LEVEL  GEOHEIRY 

ANO  ANNOTATION 


VERIF 1ED 


WIREFRAME 

WIREFRAME 

MANUAL  I 

r.rowf  iry  k 

MANUAL  L 

ADO  1 T IONS  r 

f cn i r ilai | un  | 

K 


TEST 

FILE 


Figure  4-2  Steps  To  Generate  The  IGES  Test  Files 
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5.0  TEST  METHODOLOGY 


This  section  presents  a  summary  of  the  test  methodology 
that  was  developed  for  evaluating  IGES  translators  and  applied 
in  actual  field  testing.  Since  IGES  pre-and  post-processors 
are  separate  software  packages  and  perform  different  functions, 
the  test  methodology  treats  them  independently.  Specific  de¬ 
tails  of  the  methodology  are  discussed  in  Volumes  II  and  III  of 
this  report. 

5 . 1  Post-Processor  Testing 

The  first  test  step,  as  shown  in  Figure  5-1,  involved  the 
post-processing  of  the  seven  IGES  test  files  discussed  in  the 
previous  section.  These  files  were  recorded  on  magnetic  tape 
and  were  translated  on  the  test  participant's  CAD  system.  The 
resultant  part  models  were  brought  up  at  the  CAD  station  and 
displayed.  Standard  reference  lengths  were  selected  to  ensure 
that  correct  scale  was  maintained  during  translation.  A  plot 
of  the  part  was  made  to  record  the  results  of  test  file  trans¬ 
lations.  Plots  were  used  for  comparison  with  master  Mylars 
that  depicted  the  correct  representation.  The  part  was  then 
rotated,  scaled,  and  viewed  normal  to  different  planes  to  check 
for  any  annotation  or  geometry  that  may  not  have  been  in  the 
correct  location,  or  that  could  not  be  seen  in  a  standard 
view.  The  part  was  checked  for  correct  end-point  conditions  of 
entities  by  either  using  a  chain-select  feature  or  an  NC  model 
validation  routine.  This  portion  of  the  test  checked  to  see  if 
a  model  was  connected  from  one  entity  to  another.  Entities 
that  are  properly  connected  should  share  the  same  mathematical 
endpoints . 


Figure  5-1  Post-Processor  Test  Steps 
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The  next  step  in  the  test  involved  a  functional  check  of 
the  translated  model.  Functionality  is  defined  as  the  ability 
of  the  CAD  system  to  handle  parts  as  if  they  were  created  on 
the  system  being  tested.  Each  piece  of  annotation  was  selected 
to  determine  its  entity  type  after  translation.  Text  was  then 
edited  and  moved  using  functions  that  were  normally  supported 
by  the  CAD  system  being  tested.  The  last  functionality  test 
involved  the  selection  of  entities  that  were  coded  as  group 
associativities  in  the  IGES  files.  One  member  from  the  group 
was  selected  and  if  the  translation  was  performed  correctly, 
the  remaining  group  members  were  automatically  selected. 

Surfaces  forming  the  3D  turned  part  were  checked  for  accu¬ 
racy  by  determining  the  intersection  of  lines  with  the  sur¬ 
face.  Predetermined  lines  that  intersected  the  surfaces  were 
entered  by  the  CAD  operator.  The  operator  then  found  the  in¬ 
tersection  of  the  lines  with  the  surface  using  a  CAD  system 
command.  Intersection  points  were  compared  with  the  calculated 
points . 

The  last  step  involved  a  comparison  of  the  system  generated 
plots  with  the  master  Mylars.  Geometric  inaccuracies  were 
identified,  as  well  as  problems  associated  with  annotation, 
such  as  misplaced  leaders,  text  size,  or  text  placement. 

5 . 2  Pre-Processor  Testing 

Pre-processor  evaluation  began  with  the  input  of  part  re¬ 
presentation  data  into  the  participant's  CAD  system.  Entry  of 
part  representations  was  accomplished  through  a  variety  of 
means.  Some  part  representations  were  entered  into  the  CAD 
system  by  a  designer  using  the  engineering  drawings  of  the 
parts  for  reference.  In  this  manner,  the  part  representations 
were  created  in  the  natural  working  mode  of  the  designer.  As 
this  input  method  does  not  introduce  any  test-related  biases, 
it  was  perf erred,  however,  it  was  also  time-consuming.  The 
majority  of  the  part  representations,  therefore,  were  input 
with  the  aid  of  IGES-f ormatted  data  files. 

After  the  part  representations  were  entered,  a  hardcopy  of 
the  parts,  as  they  graphically  appeared  on  the  participant's 
CAD  system,  was  obtained  as  a  record  of  the  representations 
existing  in  the  CAD  system.  The  files  were  then  pre-processed 
and  copies  of  the  pre-processed  IGES  files  were  made  on  mag¬ 
netic  tape.  This  tape  was  used  during  the  subsequent  pre-pro¬ 
cessor  evaluation. 
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Evaluation  of  pre-processed  translations  was  accomplished 
by  using  a  combination  of  three  methods  (Figure  6-1).  The 
first  method  involved  a  "full-circle"  test  of  the  IGES  trans¬ 
lators.  This  test  was  designed  to  examine  how  well  a  partici¬ 
pant  could  handle  pre-processed  files  that  were  "self"  gener¬ 
ated.  The  pre-processed  files  were  post-processed  on  the  same 
system  and  manipulated  to  ensure  part  functionality.  Hard¬ 
copies  of  the  post-processed  part  representations  were  obtained 
and  compared  with  the  original  part  drawings.  Checking  of  3D 
surfaces  was  accomplished  by  determining  the  intersection  of 
vertical  lines  with  the  surface. 

The  second  pre-processor  evaluation  method  was  based  on  the 
use  of  a  "jury  system".  For  Task  I  the  jury  was  composed  of 
two  CAD  systems  that  exhibited  a  high  level  of  implementation 
and/or  translation  capabilities  during  post-processor  testing  - 
were  selected.  Pre-processed  files  obtained  from  the  test  par¬ 
ticipants  were  post-processed  on  a  UNIGRAPHICS  and  a  General 
Electr ic-Schenectady  developed  IGES  translator,  and  evaluated 
for  completeness  and  correctness  of  translation  using  the  same 
procedures  discussed  for  the  "full-circle"  test. 

The  third  method  used  in  the  evaluation  of  pre-processed 
files  was  hand  checking  of  the  IGES  code.  Hand  checking  in¬ 
volved  comparison  of  the  parameter  data  in  a  participant’s  file 
with  the  parameter  data  of  part  features  in  the  standard  IGES 
test  file.  In  order  to  simplify  this  comparison,  the  pre-pro¬ 
cessed  files  were  run  through  a  utility  program  (developed  at 
McDonnell  Douglas  Automation)  to  sort  entities,  and  standardize 
formats  and  transformations  in  order  to  reduce  the  complexity 
of  manually  interpreting  the  IGES  files.  A  sample  of  such  a 
sort  is  presented  in  Appendix  D  of  Volume  II. 

Major  inconsistencies  discovered  through  the  first  two 
evaluation  methods  were  analyzed  by  manually  checking  entities 
in  the  subject's  IGES  file.  In  addition,  parameters  and  for¬ 
mats  of  other  selected  entities  were  spot  checked  to  ensure 
correct  translation. 
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6.0  TEST  EVALUATION 

Test  results  from  the  twelve  test  participants  were  eval¬ 
uated  on  the  basis  of  the  accuracy  and  functionality  of  pro¬ 
cessed  data.  Accuracy  is  a  measure  of  the  exactness  of  the 
processed  data  with  respect  to  the  original  material.  Function¬ 
ality  refers  to  the  ability  of  the  receiving  system  to  handle 
the  test  data  as  if  they  were  created  in  the  native  environment 

As  this  evaluation  was  based  on  the  ability  of  CAD  systems 
to  exchange  information  via  IGES,  accuracy  and  functionality 
have  been  defined  with  respect  to  the  CAD  environment.  In  order 
to  evaluate  the  utility  of  IGES  to  link  engineering  information 
with  manufacturing  functions,  a  thorough  understanding  of  the 
information  requirements  of  manufacturing  needs  to  be  develop¬ 
ed.  This  understanding  is  one  of  the  primary  outputs  of  Task 
II  of  the  PDDI  project.  Although  Task  I  test  procedures  did 
not  explicitly  evaluate  the  ability  of  IGES  to  function  as  this 
link,  the  test  results,  coupled  with  an  understanding  of  manu¬ 
facturing  requirements  from  Task  II,  provided  an  indication  as 
to  the  utility  of  IGES  for  future  linkage  implementations. 

Specific  criteria  used  to  perform  the  evaluation  were: 

•  Completeness  -  the  degree  to  which  all  part  data 
appear  in  a  display  of  the  processed  information. 

•  Legibility  -  the  degree  to  which  the  display  can  be 
unambiguously  interpreted. 

•  Geometric  Accuracy  -  the  degree  to  which  geometric 
parameters,  such  as  dimensions,  shapes,  and  inter¬ 
sections,  are  properly  represented. 

•  Functionality  -  the  degree  to  which  processed  part 
data  are  treated  as  if  they  were  generated  on  the 
system  being  tested. 

•  Attributes  -  the  degree  to  which  entity  attributes  are 
correctly  handled  by  the  test  system. 

•  Associativity  -  the  degree  to  which  associations  among 
entities  are  maintained. 

These  criteria  were  applied  on  an  ent ity- by-ent i ty  basis  to 
identify  specific  problems  with  individual  translators. 
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7.0  TEST  PROCEDURES 

It  is  the  intention  of  the  ICAM  Office  (Wr ight-Patterson  Air 
Force  Base.  Dayton,  Ohio)  to  make  these  the  procedures  and  test 
files  used  in  performing  IGES  evaluations  available  through  the 
National  Bureau  of  Standards.  This  material  may  be  used  to  test 
purchased  IGES  translators,  and  may  also  be  helpful  in  "debugging" 
evolving  translators  during  the  development  effort.  Information 
concerning  acquisiton  and  use  of  these  test  materials  can  be  ob¬ 
tained  from  Mr.  Bradford  M.  Smith  of  the  National  Bureau  of  Stan¬ 
dards  . 


o 
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8.0  SUMMARY  OF  TEST  RESULTS 

Overall.  Task  I  test  results  showed  that  no  participant  has 
implemented  a  complete  IGES  Version  1.0  preand  post-processor. 
Wireframe  geometry  and  annotation  have  been  implemented  widely 
while  surfaces  and  structure  are  minimally  implemented. 

Of  the  wireframe  geometry,  points,  lines,  and  circular  arcs 
were  successfully  translated,  while  conic  arcs  and  parametric 
splines  presented  problems  at  many  of  the  sites.  Less  than  half 
the  participants  tested  had  implemented  surfaces  and,  of  those, 
only  half  were  successful.  Only  one  participant  has  implemented 
the  more  complex  parametric  spline  surface.  Annotation  has  been 
widely  implemented,  however,  many  problems  were  encountered  with 
the  graphical  and  functional  translation  of  annotation.  Structure 
entities  have  a  very  low  level  of  implementation.  Most  of  the 
participants  dealt  successfully  with  the  IGES  format,  but  there 
was  considerable  confusion  on  the  use  and  interpretation  of  the 
global  parameters. 

Although  the  detailed  results  presented  in  Volume  II  of  this 
report  focused  on  translation  problems,  most  Task  I  test  partici¬ 
pants  were  generally  successful  in  translating  the  test  cases  as 
shown  by  the  examples  in  Figures  8-1,  8-2,  and  8-3.  Many  of  the 
problems  found  during  testing  were  site-specific,  and  should  be 
addressed  by  individual  participants.  However,  several  IGES-re- 
lated  problems  have  been  identified  in  Volume  II  of  this  report, 
and  warrant  further  work  by  the  IGES  community. 


Trans 
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9.0  CONCLUSIONS  AND  RECOMMENDATIONS 

Overall,  the  Task  I  program  has  shown  that  IGES  can  transfer 
information  currently  used  to  represent  CAD  models  of  mechanical 
parts,  and  that  there  is  widespread  support  for  IGES  within  the 
CAD  vendor/user  community.  Based  on  its  success  in  dealing  with 
CAD-to-CAD  information  exchange  as  investigated  in  Task  I,  IGES 
should  be  considered  as  an  alternative  for  the  PDDI  exchange 
format  to  be  developed  in  Task  II.  However,  there  are  numerous 
problems  with  IGES  that  are  impeding  the  progress  of  its  imple¬ 
mentation.  These  problems  must  be  addressed  and  resolved  before 
manufacturing  extensions  to  IGES  are  considered. 

9.1  IGES  REPRESENTATION  OF  MECHANICAL  PART  DATA 


Overall,  the  ability  of  IGES  to  represent  CAD  models  of 
mechanical  parts  is  very  good.  The  flexibility  available  in  the 
Standard  allows  an  implementor  to  choose  the  representation  most 
appropriate  to  the  needs  of  the  specific  CAD  system.  In  addi¬ 
tion,  an  implementor  can  develop  user-defined  entities  tailor- 
made  for  his  or  her  requirements. 

IGES  geometry  addresses  most  of  the  needs  of  current  CAD 
systems.  The  primary  problem  is  in  the  advanced  spline  curve 
and  spline  surface  representations.  Some  spline  and  surface 
types  cannot  be  exactly  represented  by  the  IGES  parametric  cubic 
curve  and  parametric  spline  surface.  In  addition,  IGES  has  no 
explicit  representation  of  offset  curve  characteristics  needed 
by  current  CAD  systems.  This  could  be  incorporated  using  IGES 
structure  capabilities. 

Although  IGES  annotation  entities  can  graphically  represent 
most  of  the  annotation  found  in  engineering  blueprints,  they  do 
not  adequately  address  the  functional  requirements  of  current 
CAD  annotation.  That  is,  the  CAD  system  cannot  extract  enough 
information  from  the  IGES  annotation  entities  to  reconstruct 
internal  representations.  If  the  annotation  is  non-functional, 
the  graphical  picture  of  the  annotation  may  look  correct  but  an 
operator  will  not  be  able  to  move,  edit  or  automatically  redi- 
raension  if  part  geometry  is  altered. 

All  of  the  identified  problem  areas  for  annotation  can  be 
addressed  by  using  the  flexible  IGES  structure  capabilities. 
However,  common  needs  among  CAD  vendors  and  users  for  annotation 
enhancements  would  be  more  efficiently  addressed  by  changes  or 
additions  to  the  annotation  entities  themselves. 
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9.2  IGES  FOR  EXCHANGE  OF  MECHANICAL  PART  DATA 

The  utility  of  IGES  for  the  exchange  of  mechanical  part 
data  was  determined  by  the  level  of  IGES  processor  development 
within  the  CAD  vendor/user  community,  and  the  success  of  those 
processors  in  translating  mechanical  part  data. 

Current  implementations  of  IGES  pre-  and  post-processors 
primarily  translate  wireframe  geometry  and  annotation.  There 
is  moderate  implementation  of  surfaces  and  minimal  implemen¬ 
tation  of  structure,  such  as  subfigures,  associativities,  prop¬ 
erties  and  MACROS.  There  is  substantial  support  for  IGES  with¬ 
in  the  vendor  and  user  communities,  and  it  is  widely  recognized 
as  an  exchange  standard.  However,  there  are  numerous  problems 
that  have  been  identified  in  these  implementations  and  within 
the  Standard  itself,  as  detailed  in  Volume  II  of  this  report. 

IGES  processor  implementation  problems  encompass  both 
implementation  errors  and  processing  practices  that  are  not 
explicitly  addressed  by  the  IGES  Standard  but  can  affect  trans¬ 
lator  effectiveness.  Implementation  errors  are  site-specific 
and  must  be  resolved  by  the  translator  developer.  One  common 
area  of  implementation  errors,  however,  is  in  the  translation 
of  curve  and  surface  geometry.  Personnel  who  develop  IGES 
software  quite  often  do  not  have  the  in-depth  mathematical 
background  necessary  to  implement  accurate  and  efficient 
geometry  translation.  In  addition,  no  guide  or  recommendation 
exists  to  aid  in  implementation  and  to  provide  a  consistent 
mathematical  approach  to  translation.  Such  a  guide  would  help 
reduce  geometry  translation  problems,  particularly  for  spline 
curves  and  surfaces. 

As  in  virtually  any  attempt  to  interface  dissimilar  systems 
with  a  specified  format,  the  IGES  approach  is  not  truly 
"neutral."  IGES  is  based  on  first-generation  commercial  CAD 
systems  representation  of  geometry  and  annotation.  Annotation, 
in  particular,  needs  to  be  enhanced  to  address  current  CAD 
annotation  functionality.  In  addition,  systems  that  differ 
significantly  from  the  IGES  representation  of  information  have 
more  difficulty  in  processing  some  IGES  entities.  As  the 
industry  evolves,  more  vendors  may  be  adopting  different  rep¬ 
resentations,  which  may  intensify  this  problem. 
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IGES  provides  a  capability  for  the  representation  of  part 
models  that  may  be  too  flexible.  Although  some  flexibility  is 
necessary  when  mapping  among  dissimilar  systems,  the  flexibil¬ 
ity  in  IGES  can  lead  to  a  loss  of  information  upon  trans¬ 
lation.  Substantial  post-processor  interpretation  is  then  re¬ 
quired  and  inconsistent  interpretation  can  result.  User-de¬ 
fined  entities  can  extend  the  IGES  representation  capabilities, 
but  implementors  of  pre-  and  post-processors  must  agree  on  the 
form  and  function  of  these  entities  in  order  to  interpret  them. 


* 


* 


* 


In  summary,  Task  I  testing  and  analysis  resulted  in  the 
following  major  conclusions: 

•  IGES  is  a  workable  approach  for  exchanging  product 
definition  data  in  a  CAD-to-CAD  environment  and  has 
the  potential  as  a  basis  for  the  PDDI  exchange  format. 

•  As  it  has  grown  to  serve  a  wide  variety  of  users,  IGES 
has  become  too  flexible  in  its  ability  to  represent 
product  data,  resulting  in  confusion  and  the  potential 
for  loss  of  data. 

•  Version  1.0,  and,  in  many  cases,  Version  2.0  contain 
numerous  instances  of  ambiguous  definitions  or  omis¬ 
sions  which  when  corrected  will  facilitate  processor 
development  and  use. 

•  Current  implementations  are  most  successful  when  deal¬ 
ing  with  simple  2D  and  3D  wireframe  geometry,  and  are 
less  successful  with  splines,  surfaces,  and  annotation. 

•  Documentation  to  aid  in  translator  development  and  use 
requires  improvement. 

•  Users  and  vendors  have  a  generally  positive  attitude 
concerning  IGES  translator  development  and  application. 

These  conclusions  have  been  conveyed  to  the  IGES  community  for 
appropriate  action. 
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